iverilogfandomcom-20200214-history
Forum:Verilog Writer for unrolling for loops
Hi, I am trying to use icarus verilog to re-write some bit of verilog code that I had. I wanted to "unroll" the "for" statements in always blocks cause I am using a third party tool which does not support "for" construct. Is there any way I can achieve this in icarus verilog compiler? I am not sure if there is a verilog-writer that dumps out the parse/elaboration tree into verilog source file? If there is one then it should not be too difficult to unroll for statements through some hack. PS: I did notice in the verilog-icarus project section that a verilog writer is a to-do item. But I was hoping a basic writer would already be in place for debug purposes. -Mahesh Someone is working on the Verilog target (writer), but it is still a work in progress. If you would like to help let use know. Cary 21:33, October 21, 2009 (UTC) ---- Hi Cary, I would like to help with the Verilog Target Writer especially a V2k to V95 writer. Basically a verilog simplifier(rewrite syntax, no synthesis). Let me know how I can help. - Mahesh -- 22:02, January 25, 2010 (UTC) ---- I'll send you some more information over the next day or two. What you'll need to start with is figuring out the target interface. This is only documented in the code and include file. The tgt-vvp code generator should support everything the compiler supports. Both the tgt-vhdl and tgt-stub interface are also worth looking at. The stub interface is good for giving you the basics, but it is not always kept up to date. The existing tgt-verilog directory may be a good place to start, but I'll need to look at it first to know for sure. I think the best way to start with this is to work from the top down. Get the code printing the module definitions. module foo; endmodule module bar; endmodule Then work on adding the arguments and definitions. After that you could add instance/gate calls, continuous assignments and the various block types. The idea would be to focus on one type and get it fully working before going on to the next type. If you only focus on what you currently need you'll end up forgetting about something. Like I said earlier I'll send more information later, but this should give you enough to get you thinking about how to start. One last thing to think about is I would try to make this support the following V2001 to V2001 and v2001 to V1995. I think 2005 needs to be added to the mix as well. So for example if you have an indexed part select it would be kept as one for 2001/2005 but would be converted to the appropriate concatenated bit selects for 1995. The input source generation would be selected with the -g flag to iverilog the output generation (<= the input generation) would be a flag passed to the writer. You probably also want a flag to specify if you want everything in one big file or multiple files. For multiple files the -o flag could be the directory where you want all the files to go. There are still many more things to think about, but that's enough for tonight. Cary 06:47, January 28, 2010 (UTC) ---- Hi Cary, thanks for the info. I will start with the simple stuff: write out Verilog AS-IS into a single file , worry about UI/Command line options later. I will work on the above over the weekend and post any additional questions. Also, is there any developer forums where we can hold these discussions? Thanks. - Mahesh -- 21:02, January 28, 2010 (UTC) ---- There is an iverilog-devel list on SourceForge and yes, that is the best place for these discussions. Waiting on the interface is fine, but make sure the decision you make in your preliminary work doesn't make adding this harder. I would suggest ignoring the interface but add support for it in the code as you write it. The values/flags can be hard coded in the top level file and changed to debug 1995 vs normal translation. I just looked at the existing tgt-verilog file and it looks OK, but there are definitely some issues. Some of the possibly less obvious ones are to remember vectors don't always start at zero and should not be normalized like we do for the vvp output. One other issue that may also need some compiler changes is can you distinguish between reg a and reg 0:0 a. They both represent a single bit, but ideally should be displayed differently. There will likely be many more subtle issue, but those can be addressed on iverilog-devel. Thanks for taking this on. Cary 21:49, January 28, 2010 (UTC) ---- I have a need for something like this, so if no one else takes/starts working on this task I'll be adding at least a 200X to 1995 translator and likely all the other possibilities. I plan to start this in a few weeks to a month depending on my schedule. Cary 17:50, February 23, 2010 (UTC)